1. Field of the Invention
This invention relates to the field of computer programming, and more particularly to a system, method, and computer program product for using the 3270 data stream architecture to communicate structured document content (such as content created in the Extensible Markup Language, or xe2x80x9cXMLxe2x80x9d).
2. Description of the Related Art
One of the challenges facing information services professionals today is the difficulty of bridging legacy mainframe host data to modern applications and their PC-based user interfaces. Most legacy host applications present their data in text-based user interfaces designed for use on specific, obsolete character-based terminals. The legacy applications were written with this character-based terminal presentation space as the only interface format in which the host data output is created, and in which host data input is expected. (xe2x80x9cPresentation spacexe2x80x9d is a term used abstractly to refer to the collection of information that together comprises the information to be displayed on a screen, as well as the control data that conveys how and where that information is to represented.)
A typical character-based terminal is the IBM Model 3270. (IBM is a registered trademark of the International Business Machines Corporation.) This terminal model was designed to display information in a matrix of characters, where the matrix consisted of 24 rows each having 80 columns. When programs were written expecting this display format, programmers would specify placement of information on the screen using specific row and column locations. Information formatted for this display is sent as a xe2x80x9cdata streamxe2x80x9d to the mechanism in the display hardware that is responsible for actually displaying the screen contents. The phrase xe2x80x9cdata streamxe2x80x9d refers to the fact that the data is sent as a linear string, or stream, of characters. This stream of characters contains both the actual textual information to be displayed on the screen, as well as information specifying where and how the text is to be displayed. xe2x80x9cWherexe2x80x9d consists of the row and column where the text is to begin, and xe2x80x9chowxe2x80x9d consists of a limited number of presentation attributes such as what color to use when displaying that text, the color of the background, etc. While the Model 3270 is a specific type of IBM display hardware, data formatted for any display having similar characteristics became a de facto standard format referred to as a xe2x80x9c3270 data streamxe2x80x9d.
Data processing systems, methods, and computer program products that use the 3270 data stream architecture have been widely used for decades. The 3270 data stream architecture has been so widely used that systems and applications using the 3270 data stream architecture are often referred to as xe2x80x9clegacyxe2x80x9d systems and xe2x80x9clegacyxe2x80x9d applications.
The 3270 data stream architecture is used to communicate between a primary logical unit and a secondary logical unit using the LU2 protocol. The primary and secondary logical units may be mainframe computers, midrange computers, personal computers, terminals, workstations, or one or more computer programs that execute on one or more of the these devices. The 3270 data stream architecture is described in many publications, including xe2x80x9cIBM 3270 Information Display System Data stream Programmer""s Referencexe2x80x9d, IBM Publication Number GA23-0059-06 (1981), which is hereby incorporated herein by reference.
As shown in FIG. 1, a data processing system 100 includes a primary logical unit 110 and a secondary logical unit 120 that communicate with each other over a network 130 using the 3270 data stream. The primary logical unit 110 may also be referred to as a host or server, and the secondary logical unit 120 may be referred to as a terminal, workstation, emulator, or client. As will be obvious to one of skill in the art, although FIG. 1 illustrates a simple data processing system 100 including one primary logical unit, one secondary logical unit 120, and a simple network connection 130, the 3270 data stream architecture is generally used to communicate among many primary logical units and secondary logical units using complex network environments. An example of a more typical data processing system using 3270 data stream architecture may be found in U.S. Pat. No. 5,649,101, entitled xe2x80x9cSystem and Method for Improving 3270 Data Stream Performance by Reducing Transmission Trafficxe2x80x9d, the disclosure of which is hereby incorporated herein by reference.
The 3270 data stream architecture was designed well before many of the recent advances in computing, such as the definition of markup languages including XML for representing structured document content. XML is a standardized formatting notation, created for structured document interchange on the World Wide Web (hereinafter, xe2x80x9cWebxe2x80x9d). XML is a tag language, where specially-designated constructs referred to as xe2x80x9ctagsxe2x80x9d are used to delimit (or xe2x80x9cmark upxe2x80x9d) information. In the general case, a tag is a keyword that identifies what the data is which is associated with the tag, and is typically composed of a character string enclosed in special characters. xe2x80x9cSpecial charactersxe2x80x9d means characters other than letters and numbers, which are defined and reserved for use with tags. Special characters are used so that a parser processing the data stream will recognize that this a tag. A tag is normally inserted preceding its associated data: a corresponding tag may also be inserted following the data, to clearly identify where that data ends. As an example of using tags, the syntax xe2x80x9c less than email greater than xe2x80x9d could be used as a tag to indicate that the character string appearing in the data stream after this tag is to be treated as an e-mail address; the syntax xe2x80x9c less than /email greater than xe2x80x9d would then be inserted after the character string, to delimit where the e-mail character string ends.
The syntax of XML is extensible, providing users the capability to define their own tags. XML is based on the Standard Generalized Markup Language (xe2x80x9cSGMLxe2x80x9d), which is an international standard for specifying document structure. XML is a simplified version of SGML, tailored to Web document content. (Refer to ISO 8879, xe2x80x9cStandard Generalized Markup Language (SGML)xe2x80x9d, (1986) for more information on SGML. Refer to xe2x80x9cExtensible Markup Language (XML), W3C Recommendation Feb. 10, 1998xe2x80x9d which is available on the World Wide Web at http://www.w3.org/TR/1998/REC-xml-19980210, for more information on XML.)
XML is widely accepted in the computer industry for defining the semantics (that is, by specifying meaningful tags) and content of the data encoded in a file. The extensible, user-defined tags enable the user to easily define a data model, which may change from one file to another. When an application generates the tags (and corresponding data) for a file according to a particular data model and transmits that file to another application that also understands this data model, the XML notation functions as a conduit, enabling a smooth transfer of information from one application to the other. By parsing the tags of the data model from the received file, the receiving application can re-create the information for rendering (i.e. display, printing, or other processing, as the generating application intended it).
Other popular markup languages include the HyperText Markup Language (xe2x80x9cHTMLxe2x80x9d), Wireless Application Protocol Binary XML (xe2x80x9cWBXMLxe2x80x9d), MathML, and VoiceXML. Each of these languages is adapted for the needs of a particular environment. HTML, for example, is adapted for general use with documents in the Web environment, and WBXML is adapted for document presentation on wireless computing devices.
It is anticipated that the interchange of documents created using a markup language will continue to increase in popularity as distributed computing becomes more pervasive in society. It would be desirable to rewrite legacy applications to receive and deliver data using the structured format defined by these modern markup languages, in order to make the application""s functionality available to users having a wide spectrum of computing device types. However, for most companies the rewrite of legacy applications represents a monumental task. Not only are there literally millions of lines of code to rewrite, but the skills that are required to program host applications (ability to use the COBOL programming language, for example) are in short supply. Furthermore, modification of existing legacy application software to change the data format used is very likely to introduce new errors, necessitating a significant testing and debugging effort.
Thus, it would be desirable to provide a technique for integrating structured document content with legacy 3270 applications to obtain the advantages of using the same existing conduit that transports the 3270 legacy data to transport the structured document content, and of using existing document processors which operate upon documents created in the various markup languages. These existing document processors include parsers and rendering software, which process a structured document for display or other presentation to a user; applications that have been written to process the content which can be extracted from a structured document; style sheet processors; etc. (A xe2x80x9cstyle sheetxe2x80x9d is a specification of a style that is to be used when presenting a document. The style specification includes information such as the font and margins to be used, the formatting layout, and other types of information that indicate how the presented document should appear. Style sheets can be used for many types of presentation of a document, including printing the document, displaying it on a video display, processing the document by a speech synthesizer, etc. Style sheets may also be utilized to describe transformations from one document type to another, e.g. from MathML to HTML, or as filters which describe transformations to reduce the amount of content while maintaining the original document type.)
Preferably, this integration of structured document content with legacy 3270 applications will not require rewriting or significantly modifying existing legacy applications.
Techniques exist that might be used for transforming legacy application data from the 3270 data stream into structured document content, for example by transforming the data stream with a specially-written transformation engine at the server on which the legacy application is executing, and then sending this transformed data to the application client. However, this approach fails to take advantage of the existing infrastructure for transporting 3270 data streams. Alternatively, the 3270 data stream can be transformed using a transformation engine at an intermediary point within the network such as a gateway. Both of these approaches suffer from the disadvantage that the existing client application software, written to process 3270 data streams, must then be replaced with application software written to process the structured document format. Furthermore, the latter approach introduces significant complexity in generating an appropriate 3270 data stream for forwarding client-generated messages back to the legacy application executing on the serverxe2x80x94in effect, simply moving the problem from one location to another. While replacing the client software may be a desirable long-term goal, providing an integration of structured document content with existing 3270 data streams enables existing software to continue to function, but with potentially significant new valuexe2x80x94and makes a phased-in approach to modifying the client software possible.
The 3270 data stream architecture communications between a primary logical unit (xe2x80x9cPLUxe2x80x9d) and a secondary logical unit (xe2x80x9cSLUxe2x80x9d) generally take place in a manner that is quite different from modem communications with which structured document content is typically transported (such as the HyperText Transfer Protocol, or xe2x80x9cHTTPxe2x80x9d). More specifically, communications between a PLU and an SLU take place using the LU2 protocol.
As is well known to those of skill in the art, the LU2 protocol is a half-duplex flip-flop (two-way alternating) protocol. A sender sets a Change Direction indicator when it has finished a transmission, and expects the next transmission to be from the receiver. Brackets delineate a series of Request/Response Units (RUs) that together provide a single transaction. Between brackets, either the PLU or the SLU may begin a new bracket. In the case of bracket contention, the SLU has priority. Only the PLU can end a bracket. Chaining allows multiple RUs to be sent in a group to the same LU. When a definite response or exception response is requested, a chain is the unit that the LU acknowledges or rejects. LU2 protocol is described in many publications, such as xe2x80x9cIBM 3174 Establishment Controller Functional Descriptionxe2x80x9d, IBM Publication No. GA23-0218-11 (1994), the disclosure of which is hereby incorporated herein by reference.
It would be desirable to pass structured document content between a PLU and an SLU that communicate with each other over an existing network using 3270 data stream architecture. Such communications should preferably take place asynchronously, and the communication of structured document content should not significantly impact conventional 3270 data stream communications.
It is therefore an object of the present invention to provide improved systems, methods, and computer program products for communicating structured document content between 3270 logical units.
It is another object of the present invention to allow asynchronous communication of structured document content between 3270 logical units.
It is still another object of the present invention to allow communication of structured document content between 3270 logical units without significantly impairing the ability of a legacy application and an end user to interact in a conventional manner.
To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, the present invention provides a method, system, and computer program product for communicating structured document content between legacy 3270 logical units. A 3270 data stream is sent between a PLU and an SLU over a network using 3270 data stream architecture, with structured document content (such as content encoded in the Extensible Markup Language, or xe2x80x9cXMLxe2x80x9d) embedded therein. The sending of 3270 data stream communications and the sending of 3270 data stream structured fields may be repeated in an arbitrary sequence, to thereby asynchronously send 3270 data streams and structured document content between the primary LU and the secondary LU. Thus, structured documents may be sent using the LU2 protocol in a manner that need not interfere with legacy communications between a 3270 application and an end user.
According to the present invention, the PLU includes a first application and the SLU includes a second application. The structured document content is passed from the first application to the second application over a network using 3270 data stream architecture by sending structured document content from the first application to the corresponding PLU, and waiting until a 3270 communication session between the PLU and the SLU is between brackets, or is in brackets, and the PLU has permission to send. If the session is between brackets, a Begin Brackets request header is sent from the PLU to the SLU. At least one request unit is sent from the PLU to the SLU, where each request unit contains a 3270 data stream structured field with the structured document content embedded therein. The embedded structured document content is then sent from the SLU to the second application.
If a synchronous reply to the structured document content is expected, then an In Brackets indicator is sent in a last of the request units containing a 3270 data stream structured field with the structured document content embedded therein. A reply may be sent from the second application to the SLU. An In Brackets, Change Direction request header is sent from the SLU to the PLU. At least one request unit is sent from the SLU to the PLU, where each request unit contains a 3270 data stream structured field with the reply embedded therein. The embedded reply is sent from the PLU to the corresponding first application. Thus, structured document content may be passed synchronously or asynchronously along with replies thereto.
Moreover, if a synchronous reply to the structured document content is not expected, an End Brackets indicator is set in a last of the request units containing a 3270 data stream structured field with the structured document content embedded therein. The request unit may include a plurality of chained request units, with the structured document content embedded therein. Thus, asynchronous communications may be provided.
Structured document content may also be passed from the second application in an SLU to a first application in a PLU by sending structured document content from the second application to the corresponding SLU and waiting until a 3270 communication session between the PLU and the SLU is Between Brackets, or is In Brackets and the SLU has permission to send. A chain indicating Change Direction in its Request Header is sent from the SLU to the PLU, this chain containing a 3270 data stream structured field with at least some of the structured document content embedded therein. If the chain does not contain all of the structured document content embedded therein, a Change Direction request header is sent from the PLU to the SLU and a chain from the SLU to the PLU indicating Change Direction in its Request Header followed by a chain from the PLU granting permission to send are repeatedly sent until all the embedded structured document content has been sent from the SLU to the PLU. The embedded structured document content is sent from the PLU to the first application after all the embedded structured document content has been sent from the SLU to the PLU.
If a synchronous reply to the embedded structured document content is expected, then a reply may be sent from the first application to the PLU. An End Brackets chain is sent from the PLU to the SLU. At least one request unit is sent from the PLU to the SLU, wherein each request unit contains a 3270 data stream structured field with the reply embedded therein. The embedded reply is sent from the SLU to the corresponding second application. Accordingly, structured document content may be passed from the second application to the first application with replies thereto being synchronously or asynchronously returned.
The present invention will now be described with reference to the following drawings, in which like reference numbers denote the same element throughout.